home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / gem / l_0399 / 254 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.3 KB
  1. Date: Thu, 2 Jun 94 11:59 BST-1
  2. From: Andre Willey <andre@cix.compulink.co.uk>
  3. Subject: SHORTCUT.INF file proposal
  4. To: gem-list@world.std.com
  5. Message-Id: <memo.271344@cix.compulink.co.uk>
  6. Precedence: bulk
  7.  
  8.  
  9. To try to avoid a lot of messages saying much the same thing, and as several
  10. people have said (here and privately) that they like the general idea of
  11. having a master shortcuts file which can be configured by the user, I
  12. thought I'd add a few thoughts which have occured in the meantime. Please
  13. keep replies *short and to the point*, and digest multiple responses where
  14. possible.
  15.  
  16. I proposed that the general format would be:
  17.  
  18.   0 ^Q ; Quit
  19.   ^  ^   ^
  20.   |  |   Comment text (not parsed; any language)
  21.   |  |
  22.   |  Keypress (user editable, maybe via a special utility?)
  23.   |
  24.   Code number, unique to a given operation (e.g. 0 for Quit, 1 for Close
  25.   Window, etc.)
  26.  
  27.  
  28. Areas which need discussing are as follows:
  29.  
  30.   * What happens if a user-requested shortcut clashes with a program's
  31.     default setting for some 'specialised' command for which we don't
  32.     have a shortcut code defined? e.g. the user has requested ^M as
  33.     'move block', but the application already has ^M defined for its
  34.     special mode for 'waving a mauve flag in a window'. Yes, I know it's
  35.     a silly example, but how should an application handle such a conflict?
  36.     Here are some suggestions for (brief!) discussion:
  37.  
  38.       Ignore the user-requested shortcut (maybe displaying a message to
  39.       say what it has done?)
  40.  
  41.       Ignore its own internal shortcut (again, displaying a messsage?)
  42.  
  43.       Prompt the user about the clash, and ask them to enter a new shortcut
  44.       for one or other command. This replacement code could maybe be saved
  45.       back to the shortcuts file, to avoid seeing the message every time
  46.       you run the program. This is simple enough for the user code, but
  47.       what about the internal program code, which has no defined code-number?
  48.       Maybe allow (in these rare cases only) a program to add an entry to
  49.       the shortcuts file in the following format:
  50.  
  51.          PROGNAME.PRG: 123  s^M ; Wave mauve flag
  52.               ^         ^    ^          ^
  53.          Application    |   Key      Comment
  54.             Name        |
  55.                         |
  56.                 Internal code (defined by application programmer)
  57.  
  58.       This would only ever be parsed by that program. Is this getting a
  59.       bit convoluted, though?
  60.  
  61.  
  62.   * Naming conventions for shortcuts. We need to use a common form for the
  63.     naming of special keys, to allow simple parsing of the file. (Internal
  64.     scan codes are to be avoided due to keyboard differences). This may
  65.     still pose language problems, though. I suggest:
  66.  
  67.       Tab, Spce, Caps, Ret, Entr, Del, Bksp, Esc, Help, Undo, Ins,
  68.       Clr (or Home?), f1-f10 (not F1-F10, to avoid confusion with 'F' key)
  69.  
  70.       The numeric keypad should be shown as [1], [2], [-], etc. What about
  71.       Enter - should this just be 'Entr', as above, or [Ent] ?
  72.  
  73.       I was going to suggest the cursor keys be defined as Up, Dn, Lt and Rt,
  74.       but that may be too language-specific. How about putting the ASCII arrow
  75.       symbols inside square brackets (otherwise a lone up-arrow or left-arrow
  76.       would be confused with Shift or submenu).
  77.  
  78.       Modifiers: ASCII 7 for Alt, ^ for Control, ASCII 1 (uparrow) for Shift
  79.                  (all historical)
  80.  
  81.  
  82.   * Menu options. There are going to be shortcuts that don't fit into
  83.     menus. This can't be avoided (e.g. some user sets up Shift-Control-Alt-
  84.     Undo, or somesuch). I suggest that an application puts shortcuts into
  85.     the menu *where it has space to do so* - but if it can't for any reason,
  86.     just flag the menu option as having some shortcut which won't fit (for
  87.     the sake of argument, use a single character like ASCII 247 or 240. 175
  88.     would be nice, but might be too easily confused with an arrow for a
  89.     submenu). If possible, suggest that an application allow space for
  90.     6-character shortcuts in its menus (only a guideline; some applications
  91.     won't be able to do this)
  92.  
  93. Andre
  94.  
  95.  +------------------------------------+-------------------------------+
  96.  |            Andre Willey            |  Cygnus Software Development  |
  97.  |  Email: andre@cix.compulink.co.uk  |  Sutton Coldfield -- England  |
  98.  |   or: ...{mcsun}!uknet!cix!andre   |  Tel:  (UK/+44) 021 308 5251  |
  99.  +------------------------------------+-------------------------------+
  100.